The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to implementations of the claimed inventions.
As businesses build larger data repositories for big data analytics, protection of data at rest is becoming a key concern among security administrators. Compliance and regulation requirements are designed to protect consumer information, personal data and customer information from unauthorized sources. As more customers store personally identifiable information (PII), sensitive, confidential or proprietary data, enterprises must ensure the privacy and confidentiality of that data—to meet both external and internal data compliance policies.
The problem of protecting data that leaves the premise and traverses the cloud is a challenge that takes precedence for today's connected businesses. Some analysts are estimating that by 2017 two-thirds of all workloads will be processed in the cloud and 1.4 zettabytes (1.4 times ten to the twenty-first power) of data will be flowing over global networks meaning that the majority of data will be in motion and remain in motion as it traverses the cloud. The concept of data at rest is undergoing redefinition—data at rest is moving into the cloud at least partly due to hosted big data analytics platforms, cloud based Hadoop file systems and cloud-based backup and disaster recovery systems.
Every industry has its own unique compliance and governance requirements. Customers need an extra level of control to meet internal or regulatory compliance requirements. IT departments and developers need to be able to build and maintain a layer of trust, transparency, compliance, and governance into business-critical apps.
Encryption makes it possible for users to encrypt their most sensitive data and files across their apps, while retaining important app functionality like search, workflow, and validation rules. Cloud-based applications need to support users to encrypt data and files, while retaining full control over the management of the encryption keys.
Existing encryption tools and services can be mapped onto virtual drives that can provide flexibility, and efficient, transportable, and deployable-in-the-public-cloud forms of partition encryption. In the aftermath of using such an encryption service, the question arises of how to handle client-driven or service-driven encryption key rotation; that is, a change to the encryption key used to protect a tenant, typically driven by the tenant after the departure of an employee with knowledge of the key, or due to regulatory, security policy, or more nefarious choices by the client. In some use cases, tenants are offered the option of configuring their system to rotate encryption keys daily, as desired. Note that the keys used to encrypt a drive are likely to be a mixture of client and service-supplied keys to help ensure adequate entropy, typically by running a combination of these keys through a deterministic one-way hash function.
For encryption key rotation, a system must maintain a list of keys to be used for decrypting and encrypting tenant data, and the system must be able to apply these keys as the software needs to read the corresponding data. Additionally, to migrate from an old encryption key to a new encryption key, existing data must be read and re-encrypted, a process which can take hours. To avoid service outages for customers who choose to rotate keys, an enterprise needs to, at times, be willing to apply old encryption keys as well as new encryption keys to data that needs to flow into their applications, at least to perform on-the-fly re-encryption.
The requirements described above for encryption key rotation complicate the view of an application: if the appropriate key cannot be used at the operating system layer to force decryption on reads and encryption on writes, the application will need greater insight into the appropriate encryption keys and the segments of the underlying disk partition to which they apply.
Existing solutions for encryption key rotation limit the amount of data per tenant to be small enough to re-encrypt at the moment of key rotation (using enough parallelism to make this fast), or take the tenant out of service (at least for writes) for the duration of re-encryption, or specially code the encryption keys into a known-and-implemented-by-the-application encryption tool.